home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX Development Foundation for IRIX 6.4
/
SGI IRIX 6.4 Development Foundation.iso
/
docs6.4
/
relnotes
/
compiler_dev
/
ch3.z
/
ch3
Wrap
Text File
|
1997-09-11
|
32KB
|
792 lines
- 1 -
Base Development 7.2 Release Notes
- 2 -
DDDDooooccccuuuummmmeeeennnntttt NNNNuuuummmmbbbbeeeerrrr 000000008888----1111777788882222----000033330000
3. _N_e_w__F_e_a_t_u_r_e_s__o_f__T_h_i_s__R_e_l_e_a_s_e
The features in this chapter are new or
significantly changed in the Base Compiler
Development software since the MIPSpro 7.1
release. Other older features of note are also
discussed.
3.1 _N_e_w__A_u_t_o_m_a_t_i_c__P_a_r_a_l_l_e_l_i_z_a_t_i_o_n__O_p_t_i_o_n
The 7.2 release of the MIPSpro compilers marks a
major revision of the auto-parallelizer. The new
product incorporates automatic parallelization
into the other optimizations performed by the
MIPSpro compilers. Previous versions relied on
preprocessors to provide source-to-source
conversions prior to compilation. This change
provides several benefits to developers:
Automatic parallelization is integrated with
optimizations for single processors
A set of options and pragmas consistent with the
rest of the MIPSpro compilers
Better run-time and compile-time performance
For more information, please refer to the
auto_p(5) man pages.
NOTE: In order to run the new automatic
parallelization, you must purchase the MIPSpro
Auto Parallelization Option (SC4-APO-7.2) and
install the license for it (FEATURE name string
= auto_pp).
3.2 _C_o_m_p_i_l_e_r__S_y_s_t_e_m
This section lists changes and additions to
compilers and development tools since the
MIPSpro 7.1 release.
- 3 -
3.3 _N_e_w__O_p_t_i_o_n_s__a_n_d__D_e_f_a_u_l_t_s
A new -_D_E_B_U_G:_o_p_t_i_o_n control group has been
created to allow insertion of code to assist in
the debugging of programs. For example,
-_D_E_B_U_G:_d_i_v__c_h_e_c_k=_N replaces -_T_E_N_V:_c_h_e_c_k__d_i_v=_N
and the 7.2 compiler, by default, inserts code
to check for divide by zero (N=1).
_N_O_T_E: The default value for -_T_E_N_V:_c_h_e_c_k__d_i_v=_N
under MIPSpro 7.1 was N=0 (no checks).
For more information, please refer to the _c_c(1)
and _D_E_B_U_G__g_r_o_u_p(5) man pages.
The -_L_I_S_T: options control group has been
enhanced to the create a listing file (.l) that
contains the values of all flags modified,
directly in the command line, or indirectly as a
side effect of other options. For example:
% cc -n32 -LIST:options=ON foo.c
will create foo.l which contains a listing that
contains the default values of certain options
from the -OPT, -LNO, -TARG and -TENV option
control groups.
The following command:
% cc -n32 -LIST:all_options=ON foo.c
will create foo.l which contains a listing that
contains the default values of all options from
all of the option control groups.
For more information, please refer to the _c_c(1)
man page.
3.4 _O_b_s_o_l_e_t_e__O_p_t_i_o_n_s
Several compile-time flags have been obsoleted.
These include: -_T_E_N_V:_m_i_s_a_l_i_g_n_e_m_n_t=_N,
-_T_E_N_V:_a_l_i_g_n__e_x_t_e_r_n=_N and -_T_E_N_V:_a_l_i_g_n_e_d=_T_R_U_E.
Their use will generate a warning message in
both the compiler front-end and backend. For
example:
- 4 -
% cc -n32 -TENV:misalignment=3 reshape.c
Warning: Obsolete option "-TENV:misalignment=3" -- ignored
Warning: Obsolete option "-TENV:misalignment=3" -- ignored
The -_T_E_N_V:_v_a_r_a_r_g_s__p_r_o_t_o_t_y_p_e_s=_T_R_U_E flag has been
replaced by -_D_E_B_U_G:_v_a_r_a_r_g_s__p_r_o_t_o_t_y_p_e_s=_T_R_U_E.
For more information, please refer to the _c_c(1)
and _D_E_B_U_G__g_r_o_u_p(5) man pages.
3.5 _C_o_m_p_i_l_e_r__D_e_f_a_u_l_t_s
When invoking the compiler, ----33332222 ----mmmmiiiippppssss2222 is
assumed on all machines except those based on
the R8000 processor. There, the compilations
default to ----66664444 ----mmmmiiiippppssss4444. These defaults can, of
course, be overridden at the command line or
through the use of the _S_G_I__A_B_I environment
variable. For more information on these flags,
please refer to the _c_c(1), _f_7_7(1) and _a_b_i(5) man
pages.
The MIPSpro 7.1 compiler introduced a new method
by which the user can customize the Application
Binary Interface (ABI), instruction set
architecture (ISA) and processor type used in
compilations where they are not explicitly
specified. Under this method, the
COMPILER_DEFAULTS_PATH environment variable can
be set to a colon separated list of paths where
the compiler will look for a _c_o_m_p_i_l_e_r._d_e_f_a_u_l_t_s
file. If no _c_o_m_p_i_l_e_r._d_e_f_a_u_l_t_s file is found or
if the environment variable is not set, the
compiler looks for /_e_t_c/_c_o_m_p_i_l_e_r._d_e_f_a_u_l_t_s. If
that file is not found either, the compiler
resorts to the built-in defaults described in
the _c_c(1)man pages and above. For a description
of the specification format of this file, please
refer to the _c_c(1)man pages.
3.6 _W_H_I_R_L _I_n_t_e_r_m_e_d_i_a_t_e _O_b_j_e_c_t _F_i_l_e _F_o_r_m_a_t
_C_h_a_n_g_e_s
The format of WHIRL Intermediate Object files
has changed. If you have WHIRL intermediate
(.o) files left over from compilations using
- 5 -
MIPSpro 7.1 with interprocedural optimization
enabled (i.e. -IPA), you must recompile the
entire set of files.
3.7 _A_B_I__D_e_v_e_l_o_p_m_e_n_t
For information about ABI development issues,
see the man pages _a_b_i_c_c(_1), _a_b_i_l_d(_1),
_c_h_e_c_k__a_b_i__c_o_m_p_l_i_a_n_c_e, _c_h_e_c_k__a_b_i__i_n_t_e_r_f_a_c_e and
_c_h_e_c_k__f_o_r__s_y_s_c_a_l_l_s.
3.8 _C_o_n_t_r_o_l_l_i_n_g__CCCC_GGGG__c_o_m_p_i_l_e_r__o_p_t_i_m_i_z_a_t_i_o_n_s
_C_G is the code-generation part of the compiler.
There are choices to be made in many parts of
_C_G, e.g. what conditional constructs should be
if-converted, or how much should a loop be
unrolled. In most cases the compiler should be
making reasonable decisions. But there are
still times when performance can be improved by
modifying the default behavior.
The following sections describe a few of the
ways that _C_G can be controlled by the user.
+o Non-loop if-conversion can be turned off
with -_C_G:_i_f_c__n_o_n__l_o_o_p=_o_f_f. Currently non-
loop if-conversion only applies to simple
if-then or if-then-else constructs with a
very few conditionally executed
instructions, so it should usually be
advantageous to do the if-conversion. (In
fact we may increase the amount of this
kind of if-conversion we do in future
releases). One reason the if-conversion
could be sub-optimal is that one of the two
paths through the code might be rarely
executed. (This can be controlled with
-_C_G:_b_o_d_y__f_r_e_q__f_b=_n. If some block in the
loop has frequency less than 1/n times the
frequency of the loop head, if-conversion
for that loop is disabled.)
+o If-conversion of innermost loops is
disabled with -_C_G:_i_f__c_o_n_v_e_r_s_i_o_n=_o_f_f. The
most likely reason that this would be
useful is that if-conversion has increased
the number of instructions in the loop by a
lot, and the loop is Software Pipelined, so
that there is no opportunity for
- 6 -
reverse_if_conversion to undo the damage.
Another way to protect against this
possibility is by setting the value of
-_C_G:_b_o_d_y__i_f_c__r_a_t_i_o. For example, if
-_C_G:_b_o_d_y__i_f_c__r_a_t_i_o=_2, and the number of
instructions in the loop grows by more than
a factor of 2 due to if-conversion, then
the if-conversion will be undone (and of
course there will then be no opportunity to
Software Pipeline that loop).
+o Cross iteration optimizations can be
disabled with -_C_G:_v_e_c_t_o_r__r_w__r_e_m_o_v_a_l=_o_f_f
(for read-read or read-write
optimizations), -_C_G:_v_e_c_t_o_r__w_w__r_e_m_o_v_a_l=_o_f_f
(for write-write optimizations), and/or
-_C_G:_c_r_o_s_s__i_t_e_r__c_s_e__r_e_m_o_v_a_l=_o_f_f (for common
sub-expression elimination). The reason to
do this is that these optimizations can
increase register pressure.
+o The unroll amount may be increased or
decreased. There is a heuristic controlled
by -_O_P_T:_u_n_r_o_l_l__a_n_a_l_y_s_i_s (on by default)
which is generally trying to minimize
unrolling, because less unrolling leads to
smaller code size and faster compilation.
Usually the only thing that makes it unroll
too much is its attempt to minimize the
cost of penalties for taken branches. If
you set the penalty for such a branch to 0
(-_C_G:_b_r_a_n_c_h__t_a_k_e_n__p_e_n_a_l_t_y=_0), or increase
the cost for taken branches that the
heuristic will tolerate (increase the value
of -_C_G:_u_n_r_o_l_l__a_n_a_l_y_s_i_s__t_h_r_e_s_h_o_l_d from its
default value of .1), you can probably
avoid having loops unrolled too much. You
can also change the upper bound for the
amount of unrolling with -_O_P_T:_u_n_r_o_l_l__t_i_m_e_s
(default is 8) or -_O_P_T:_u_n_r_o_l_l__s_i_z_e (the
number of instructions in the unrolled
body, current default is 80). In case the
heuristic is limiting unrolling too much,
it can be disabled with
-_O_P_T:_u_n_r_o_l_l__a_n_a_l_y_s_i_s=_o_f_f.
+o Software Pipelining can be disabled with
-_O_P_T:_s_w_p=_o_f_f. As far as CG is concerned,
-_O_3 -_O_P_T:_s_w_p=_o_f_f is the same as -_O_2.
However, since LNO does not run at -_O_2, the
input to CG can be very different, and the
- 7 -
available aliasing information can be very
different.
+o Reverse_if_conversion for non SWP'd loops
can be disabled with -_C_G:_r_e_v_e_r_s_e__i_f=_o_f_f.
3.9 _C_h_a_n_g_e_s__t_o__dddd_bbbb_xxxx_(_1_)
+o _d_b_x has been enhanced to allow debugging of
Fortran 90 allocatable arrays.
+o _d_b_x has been enhanced to allow debugging of
Fortran 90 assumed shape arrays.
+o _d_b_x has been enhanced to allow debugging of
C++ programs created with the -gslim
option. This option limits the amount of
debugging information generated by the C++
compiler for class definitions. You should
consider using this option on large
applications when you experience bloated
object files, executables, or DSOs when
compiling with -g. For more information
refer to the CC(1) man pages.
+o _d_b_x has been enhanced to allow debugging of
C++ code that contains exception handlers.
For more information, refer to the _D_B_X
_U_s_e_r'_s _G_u_i_d_e.
+o _d_b_x has been enchanced to support pthreads
debugging. For more information, refer to
the _D_B_X _U_s_e_r'_s _G_u_i_d_e.
3.10 _C_h_a_n_g_e_s__t_o__t_h_e__l_i_n_k_e_r__llll_dddd_(_1_)
This linker provides some new features and
better performance. For more information refer
to the _l_d(1) man page.
+o As of release 5.0.1, the linker can adjust
executables to avoid certain problems with
early versions of the R4000. If the
----nnnnoooo____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp flag is on (it is on by
default), small amounts of padding are
added between component objects to avoid
placing a branch instruction at the end of
a page. Slightly smaller executables and
significantly faster executables can result
by turning this option off (using the
- 8 -
----aaaalllllllloooowwww____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp flag). Binaries built
either way should be compatible across all
Silicon Graphics systems, but those made
with ----nnnnoooo____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp (the default) often
show performance gains on R4000 systems.
These flags are irrelevant for programs
compiled with ----mmmmiiiippppssss4444 because the R8000 and
R10000 processors do not have this hardware
bug and no padding is performed by the
linker.
However, early versions of the R5000 may
have problems if a jump or branch
instruction occurs at an address 8 bytes
before the end of an odd-numbered page, and
if a load or store instruction immediately
follows the jump or branch instruction. The
6.2 and above releases of the linker work
around this problem by padding sections of
object files that exhibit the
characteristics described above. This
occurs by default for object files compiled
for ----mmmmiiiippppssss4444. Binaries can be built without
this fix by using the
----aaaalllllllloooowwww____rrrr5555kkkk____jjjjuuuummmmpppp____aaaatttt____eeeeoooopppp option.
+o The 6.2 release of the linker introduced an
experimental new feature enabled by the
----mmmmuuuullllttttiiiiggggooootttt option. If you experience GOT
Overflow problems in building your
applications, you should try relinking with
the ----mmmmuuuullllttttiiiiggggooootttt option as an alternative to
recompiling with ----xxxxggggooootttt.
+o New options have been added to _l_d(1) for
aligning variables in the global
uninitialized data area (_b_s_s). See the
manual page for _l_d(1) for options with
names beginning with ----XXXX. These new options
are unique to IRIX and might change across
releases.
3.11 _A_s_s_e_m_b_l_e_r__(_aaaa_ssss_(_1_)_)
+o As of 6.2, the assembler supports 64-bit
instructions, and can generate 64-bit ELF
object files. The COFF format is not
supported. The 64-bit and N32 objects
contain DWARF debugging support rather than
MDEBUG.
- 9 -
+o The calling conventions and register usage
for 64-bit objects is different from the
32-bit conventions, so you should become
familiar with the new conventions. The
_M_I_P_S_p_r_o _6_4-_B_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e
is useful for porting code from 32 to 64
bits. Also see the standard include files
<_r_e_g_d_e_f._h> and <_a_s_m._h> which are
parameterized for 32-bit or 64-bit code.
+o Most of the optimizations like software
pipelining and cross-basic-block scheduling
have been removed from the assembler; these
optimizations are now done in the back-end,
and thus only happen for high-level code.
The assembler still does instruction
scheduling for the user.
+o There are three new assembler directives
for the generation of 64-bit PIC
(Position-Independent Code). These
directives are ignored if not doing a 64-
bit shared (PIC) compile.
+o ._c_p_s_e_t_u_p _r_e_g, _r_e_g_2/_o_f_f_s_e_t, _l_a_b_e_l
By convention, reg == t9, and the label is
the procedure entry. The second argument
can be either another register (for the
case of a leaf routine with no frame) or a
stack offset, and is used to store the
value of $gp. This directive expands into:
ssssdddd ggggpppp,,,, ooooffffffffsssseeeetttt((((sssspppp))))
lllluuuuiiii ggggpppp,,,, %%%%hhhhiiii((((%%%%ggggpppp____rrrreeeellll((((llllaaaabbbbeeeellll))))))))
ddddaaaaddddddddiiiiuuuu ggggpppp,,,, ggggpppp,,,, %%%%lllloooo((((%%%%ggggpppp____rrrreeeellll((((llllaaaabbbbeeeellll))))))))
ddddaaaadddddddduuuu ggggpppp,,,, ggggpppp,,,, rrrreeeegggg
+o ._c_p_r_e_t_u_r_n
This directive expands into:
lllldddd ggggpppp,,,, ooooffffffffsssseeeetttt((((sssspppp))))
where "offset" is the same value used in
the previous .cpsetup.
+o The .cpsetup/.cpreturn sequence replaces
the .cpload/.cprestore sequence that is
used in 32-bit PIC code.
- 10 -
+o The other new directive is
._c_p_l_o_c_a_l _r_e_g_1
It specifies a register (typically not $gp)
to be used as context pointer. It has
effect only within a procedure (i.e., it is
turned off automatically at the end of each
procedure).
There are two new directives in the 7.00
-n32/-64 assembler:
+o ._d_y_n_s_y_m _n_a_m_e _v_a_l_u_e
This specifies the st_other field of the
symbol, which can be "sto_default",
"sto_internal", "sto_hidden", or
"sto_protected".
+o ._g_p_v_a_l_u_e _v_a_l_u_e
The gp value is used in %gp_rel relocations
as an offset for the addend. By default
the value is 0.
Chapter 8 of the _M_I_P_S_p_r_o _A_s_s_e_m_b_l_y _L_a_n_g_u_a_g_e
_G_u_i_d_e contains descriptions of all of the
directives supported by the assembler.
+o The _M_I_P_S_p_r_o _N_3_2 _A_B_I _H_a_n_d_b_o_o_k and the
_M_I_P_S_p_r_o _6_4-_b_i_t _P_o_r_t_i_n_g _a_n_d _T_r_a_n_s_i_t_i_o_n _G_u_i_d_e
contain examples of how to write assembly
language programs for the the N32 and 64-
bit ABI's respectively.
3.12 _L_i_b_r_a_r_i_e_s
The following changes to the libraries that are
part of the compiler system were made in the 7.1
release.
3.12.1 _R_e_p_a_c_k_a_g_i_n_g__o_f__N_3_2__S_u_b_s_y_s_t_e_m_s The
_c_o_m_p_i_l_e_r__d_e_v._s_w_3_2 subsystems have been bundled
into the _c_o_m_p_i_l_e_r__d_e_v._s_w subsystems and are no
longer present as independent subsystems.
- 11 -
3.12.2 _D_i_s_c_o_n_t_i_n_u_a_n_c_e _o_f _N_3_2 _a_n_d _6_4-_b_i_t _N_o_n-
_s_h_a_r_e_d _L_i_b_r_a_r_i_e_s N32 and 64-bit versions of
non-shared libraries for SPEC
(_c_o_m_p_i_l_e_r__d_e_v._s_w_3_2._s_p_e_c_l_i_b and
_c_o_m_p_i_l_e_r__d_e_v._s_w_6_4._s_p_e_c_l_i_b) are no longer being
shipped.
The following changes to the libraries that are
part of the compiler system were made in the 6.2
release.
+o The floating point exception handler
package (libfpe) has been rewritten and
released with support for programs compiled
under ----mmmmiiiippppssss3333 or ----mmmmiiiippppssss4444. Refer to the
_f_s_i_g_f_p_e(3f) and _h_a_n_d_l_e__s_i_g_f_p_e_s(3c) man
pages.
+o Fast floating point libraries (libfastm)
tuned for the R5000, R8000 and R10000,
respectively, are now available when doing
compilation for the 64-bit and N32 ABI's.
New ----rrrr5555000000000000, ----rrrr8888000000000000 and ----rrrr11110000000000000000 compiler
flags are provided which add the paths of
these libraries to the head of the library
search path. For more information refer to
the _c_c(1) and _f_7_7(1) man pages.
3.13 _P_e_r_f_o_r_m_a_n_c_e__T_o_o_l_s
This section includes changes to _p_i_x_i_e(1),
_p_i_x_s_t_a_t_s(1), _p_r_o_f(1).
+o As of the 7.0 release, _p_i_x_i_e(1),
_p_i_x_s_t_a_t_s(1), and _p_r_o_f(1) are no longer
supported. Their functionality has been
integrated into a new product called
SpeedShop. Interested users are referred to
SpeedShop's release notes for more
information.
3.14 _L_i_b_r_a_r_y__a_n_d__S_y_s_t_e_m__C_a_l_l__F_u_n_c_t_i_o_n_a_l_i_t_y
The following additions and changes were made to
library and system call functionality between
versions 5.3 and 6.2 of the IRIS Development
Option (now being replaced by the IRIX
Development Foundation).
- 12 -
+o The MIPSpro C compiler supports long double
arithmetic using the ANSI C standard
syntax. Most of the standard
transcendental functions in _l_i_b_m and _l_i_b_c
are supported. See specific man pages for
names and prototypes. Most of the long
double routines are named by prefixing the
letter 'q' to the double precision
routine's name; for example, _q_s_i_n is the
long double version of _s_i_n.
The following long double routines are NOT
supported in this release: _a_c_o_s_h, _a_s_i_n_h,
_a_t_a_n_h, _c_b_r_t, _d_r_a_n_d_4_8, _d_r_e_m, _e_r_a_n_d_4_8, _e_x_p_m_1.
See the man page for _m_a_t_h(3M) for details
regarding long double arithmetic. Note
that long double operations on this system
are only supported in "round to nearest
rounding" mode (the default). The system
must be in "round to nearest rounding" mode
when issuing long double arithmetic
operations or calling any of the long
double functions, or incorrect answers will
result.